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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and 
Systems (SES). 

The present document is part 2 of a multi-part deliverable covering the Broadband Satellite Multimedia (BSM) 
Regenerative SatelHte Mesh - B (RSM-B); DVB-S/DVB-RCS family for regenerative satellites, as identified below: 

Parti: "System overview"; 

Part 2: "Satellite Link Control layer"; 

Part 3: "Connection control protocol"; 

Part 4: "Specific Management Information Base". 
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Scope 



The present document defines the Satellite Link Layer and the Network Layer used within SES BSM Regenerative 
Satellite Mesh - B (RSM-B) to provide connections in a DVB-RCS network using Type A terminals. This corresponds 
to TS 102 429-2 as shown in the figure 1.1. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in EN 301 790 [1] and the following apply: 

Connection Control Protocol (C2P): protocol that provides the interaction between RCSTs and NCC to support 
set-up, modification and release of connections and channel bandwidth modification 

control plane: the control plane has a layered structure and performs the connection control functions; it deals with the 
signalling necessary to set up, supervise and release connections 

Digital Video Broadcasting Return Satellite Channel (DVB-RCS): protocol for an interaction (or return) channel in 
satellite links 

Digital Video Broadcasting via Satellite (DVB-S): protocol for broadcasting TV signals and by extension data over 
satellite 

interactive network: satellite interactive network where a certain DVB-RCS RCST belongs to 

management plane: plane that provides two types of functions, namely layer management and plane management 
functions 
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Management Station (MS): controls and manages the RSM-B network and is composed of three elements: 

the Network Control Center (NCC); 

the Network Management Center (NMC); 

the satellite terminal of the MS (NCC_RCST), which supports the modulation and demodulation functions to 
access to the satellite. 

multicast: communication capability, which denotes unidirectional distribution from a single source access point to a 
number of specified destination, access points 

Network Control Center (NCC): RSM-B network element which controls the Interactive Network, serves users 
satellite access, and manages the OBP configuration 

Network Management Center (NMC): RSM-B network element composed in charge of element management 
functions and for the network and service provisioning and management 

On Board Processor (OBP): satellite payload digital processor on-board the satellite that allows MPEG packets 
switching from up-link to downlink beams in a flexible way 

Return Channel Satellite Terminal (RCST): low cost and high performance RSM-B network element installed in the 
user premises that provides interfaces with final users and allows its users access to users of others RCSTs or to external 
users of terrestrial networks through the RSGW, or to services delivered by the Service Provider attached to the RSGW 

Gateway Return Channel Satellite Terminal (GW_RCST): RSM-B RCST installed inside an RSGW with enhanced 
properties in routing, IP multicast, connection control and management 

Regenerative Satellite GateWay (RSGW): RSM-B network element provides the interface between RSM-B network 
and external users of terrestrial networks such as PSTN or ISDN and with external Service Providers 

NOTE: A RSGW is composed by a Gateway and one or several GW_RCST. A Gateway includes all the network 
elements that will assure the interface with terrestrial networks (e.g. IP router. Voice gateway. Video 
gateway. Gatekeeper). 

Quality of Service (QoS): measure of the parameters of a network that influence perceived quality of communications, 
including the delay, jitter, bandwidth, and packet loss that packets sent by the application experience when being 
transferred by the network 

user plane: plane which has a layered structure and provides user information on flow transfer, along with associated 
controls for flow control and recovery from errors 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in EN 301 790 [1] and the following apply: 

BE Best Effort 

BSM Broadband Satellite Multimedia 

CAC Connection Admission Control 

ChModReq Channel Modify Request 

ChModResp Channel Modify Response 

CLI Command Line Interface 

CMT Correction Message Table 

cnx connection 

CnxEstReq Connection Establishment Request 

CnxEstResp Connection Establishment Response 

CnxRelReq Connection Release Request 

CnxRelResp Connection Release Response 

CRA Constant Rate Assignment 

CSC Common Signalling Channel 

D/L DownLink 

DAMA Demand Assigned Multiple Access 

DiffServ Internet Differentiated Services 

DSCP DiffServ Code Point 
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DULM Data Unit Labelling Method 

DVB Digital Video Broadcast 

DVB-RCS Digital Video Broadcast-Return Channel by Signalling 

DVB-S Digital Video Broadcast via Satellite 

DVB-S2 Digital Video Broadcasting by Satellite transmission 2"'^ Generation 

ETSI European Telecommunications Standards Institute 

FCA Free Capacity Assignment 

FCT Frame Composition Table 

FEC Forward Error Correction 

FLS Forward Link Signal 

fwd forward 

GW_RCST Gateway Return Channel Satellite Terminal 

HP High Priority 

HPj High Priority jitter sensitive 

IDU InDoor Unit 

IE Information Element 

IETF Internet Engineering Task Force 

IGMP Internet Group Management Protocol 

IP Internet Protocol 

ISDN Integrated Services Digital Network 

ISO International Standards Organisation 

kbps kilo bits per second (thousands of bits per second) 

LP Low Priority 

Isb least significant bit 

M&C Management and Control 

MAC Medium Access Control 

MBGP Multicast Border Gateway Protocol 

Mbps Mega bits per second (millions of bits per second) 

MER Multicast Edge Router 

MF-TDMA Multi-Frequency Time Division Multiple Access 

MIB Management Information Base 

MMT Multicast Map Table 

MPEG Moving Picture Experts Group 

MPEG2-TS MPEG2 Transport Stream 

MS Management Station 

msb most significant bit 

MSDP Multicast Source Discovery Protocol 

NAT Network Address Translation 

NCC Network Control Center 

NCR Network Clock Reference 

NIT Network Information Table 

NMC Network Management Center 

OBP On Board Processor 

ODU OutDoorUnit 

PAT Program Association Table 

PCR Program Clock Reference 

PDR Peak Data Rate 

PID Program IDentifier 

PNP Power Noise Phase 

PSTN Public Switched Telephone Network 

QoS Quality of Service 

QPSK Quadrature Phase Shift Keying 

RBDC Rate Based Dynamic Capacity 

RCST Return Channel Satellite Terminal 

req request 

RMT RCS Map Table 

RS Reed Salomon 

RSGW Regenerative Satellite Gate Way 

RSM Regenerative Satellite Mesh 

rtn return 

SAC SatelUte Access Control 

SCT Superframe Composition Table 
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SDR Sustainable Data Rate 

SI Service Information 

SLC Satellite Link Control 

SNMP Simple Network Management Protocol 

SP Service Provider 

SPT Satellite Position Table 

StrP Streaming Priority 

SYNC SYNChronization burst type 

TBTP Terminal Bursts Time Plan 

TC Turbo Code 

TCP Transmission Control Protocol 

TCT Time-slit Composition Table 

TDM Time-Division Multiplex 

TDMA Time Division Multiple Access 

TIM Terminal Information Message 

TRF Traffic (burst type) 

TS Transport Stream 

TTL Time To Live 

U/L UpLink 

UDP User Datagram Protocol 

UI User Interface 

UT User Terminal 

VPN Virtually Private Network 



Satellite Link Control Layer 



4.1 



Overview 



In close connection with EN 301 790 [1], the Satellite Link Control (SLC) Layer, is constituted as a set of control 
functions and mechanisms which mainly ensure the access of IP flows to the physical layer and controls their transfer 
between distant points. 

The functions identified are: 

• Session control function (forward link acquisition, logon/logoff procedure. Synchronization procedure). 

• Connection control function in charge of the establishment, release and modification of connections between 
two or several RCST's and between one RCST and the NCC. In the user plane, the connection control 
functions interfaces with the upper layers through interworking functions. These functions mainly insure a 
classification of incoming IP flows allowing their mapping on a certain connection (connection aggregation). 

• Resource control function in charge of the capacity request generation, buffer scheduling and traffic emission 
control, allocation message processing (TBTP) and signalling emission control. 
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Figure 4.1 : RCST SLC layer functional brealtdown 



4.2 



Session control 



The RSM-B Session Control procedures are based on EN 301 790 [1]. DVB-RCS is an open standard, therefore the 
particularization for RSM-B system are detailed in the following sections. 

4.2.1 Signalling messages 

This clause recalls the major messages exchanged between the RCSTs and the NCC in the session control context. 



4.2.1.1 



Forward link signalling from NCC to RCST 



TIM-Terminal Information Message, could be either Global (TIM_b) or Individual (TIM_u) message sent in 
DSM-CC (Digital Storage Media Command and Control) private section, using a reserved broadcast or RCST MAC 
address containing static or quasi static information about the forward and return link. 

CMT Correction Message Table (and the Correction Message Descriptor attached to the TIM_u) to include power, 
frequency and timing corrections to be applied by the RCST resulting from the SYNC burst preamble measurements (or 
the first CSC burst preamble during a logon process). The RCST identifier group_id, logon_id (MAC address) are 
extracted from the SYNC burst payload to identify the RCST measured. 
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4.2.1 .2 Return signalling from RCST to NCC 

The type of carrier authorized for the RCST logon and synchronization burst emission is always a CI carrier, as 
described in TS 102 429-1 [3]. 

The CSC burst , Common Signalling Channel, is made of a preamble, followed by the CSC payload. The CSC burst 
is transmitted in random access by the RCST: 

• To identify itself at logon via specific information (RCST capabilities and MAC address) extracted from the 
CSC burst payload. 

• To initiate frequency and timing Synchronization and RF power adjustment via estimations on the CSC burst 
preamble and returned by the NCC (in the TIM_u Correction Message Descriptor) for application if needed. 

The SYNC burst, Synchronization, is made of a preamble, followed by the SAC field. The SYNC burst is: 

• Used for fine Synchronization and to maintain it during session via repetitive frequency, timing and power 
estimations on the SYNC burst preamble and returned by the NCC (in the CMT) for application if needed. 

• Used for capacity and logoff request, and Synchronization achievement notification via the SAC field 
extracted from the SYNC burst payload. 

4.2.2 RCST Session Control procedure 

The following specific principles have been followed: 

• Session Control activity starts with Initial Synchronization (FLS acquisition). 
The DVB optional "coarse Synchronization" is not applied within the RSM-B system. 



• 



• Power control and Synchronization : the required corrections to apply are returned by the NCC to the RCST 
from estimations performed by the OBP on the CSC and SYNC burst preamble. 

4.2.2.1 Session Control procedures definition 

A Session is defined as the "time period" whereby the RCST is logged-on into the RSM-B network. To enter and quit 
the RSM-B network, the RCST has to logon and logoff into the network following the sequence of procedures detailed 
in EN 301 790 [1]. These phases are summarized below: 

Initial Synchronization procedure: The RCST acquires the forward link signalling and the network clock (NCR) 
required to get all the information about the RSM-B network. Subsequently all the information about the RSM-B is 
received (see clause 4.2.2.2). 

Log-on procedure: To allow the NCC to identify the RCST (via the MAC address) and to allow the RCST to receive 
its logical identifier valid for the duration of the session (Group_id, Logon_id, PIDs, SYNC burst, etc.). The RCST also 
starts its Synchronization and RF power adjustment (see clause 4.2.2.3). 

Fine Synchronization procedure: For the RCST to achieve timing and frequency Synchronization and power 
adjustment. As soon as the RCST is logged, a SYNC slot on a Synchronization carrier is allocated to it up to log-off 
procedure (see clause 4.2.2.4). 

Synchronization Maintenance procedure: Periodical repetition of the fine Synchronization (see clause 4.2.2.5). 

Log-off procedure: To release all physical and logical resources, and exit from the network. The RCST will notify its 
logoff sending a SYNC SAC to the NCC (see clause 4.2.2.6). 

Corresponding to these procedures, the RCST can be in one of the following states: 

Receive Sync state: Initial Synchronization procedure achieved (forward link acquired) and ready for logon procedure 
initiation. The RCST may initiate the logon procedure based on: 

End-user request (through a CLI or HTTP interface), an stimulus transition. 

An NCC wake-up request (see clause 4.2.2.8) equivalent to Transmit_Enable transition. 
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Ready for fine sync state: After logon procedure achieved (detected by the NCC), the RCST is ready for fine 
Synchronization procedure initiation. 

Fine sync state: Fine Synchronization procedure is achieved and the RCST is ready for sending traffic. 

Stand-by state: Anomalies have been detected during any one of procedures. Consequently, the RCST re-starts the 
initial Synchronization procedure. 

Off state: The RCST is powered off (inactive) or has been logged off (out of the RSM-B network). 

Hold state: This specific RCST state is activated by the NCC at any time of the RCST session (due to an operator 
decision). The NCC transmits the RCST status field transmit_disable set to 1 contained within the TIM_u 
(Transmit_Disable transition) to force the RCST in the hold state (see clause 4.2.2.7). The RCST is authorized to 
proceed again the "Initial Synchronization" procedure only after receiving the "transmit_disable" field set to from the 
NCC (see clause 4.2.2.8). In case of power-off while being in the hold state, the RCST should remain in hold state after 
a new RCST power on. The RCST should then acquire the forward link and immediately returns into hold state to wait 
for a "transmit_disable" field set to from the NCC (transmit_enable transition). 

NOTE: The RCST must restart the initial synchronization procedure to enter into the "Receive Sync state" or 
"Hold state" (according the Tx_disable flag value) in the following cases: 

Logoff procedure initiated by the NCC. 

Logon_fail_(busy) notified by the NCC. 

Logon_denied notified by the NCC (with Tx_disable set to 1). 

NCR not received for configurable seconds. 

Fine synchronization not achieved after consecutive SYNC attempts. 

Logon TIM_u not received after configurable consecutive CSC attempts. 

CMT burst correction not received after configurable consecutive SYNCs. 
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Figure 4.2: RCST Synchronization state diagram 

4.2.2.2 Initial Synchronization procedure 

The initial Synchronization procedure of the RCST is performed according to the procedures defined in EN 301 790[1]. 
These procedures are described hereafter: 

• RCST power up and software initialization. 

• Physical link Synchronization (1). 

• Loading network information from NIT (2) and localization of relevant Forward Link Signalling Service from 
RMT (3, 4). 

• Extraction of the tables characterizing the service from PAT and PMT (5, 6). 

• NCR Synchronization in order to lock ground local clock to the Satellite Network clock reference (7). 

DVB-RCS specific tables loading, using PIDs listed in the PMT of relevant ELS service: 

■ To get the satellite ephemeris for transmission error correction (8). 

■ To get the framing structure of RSM-B network of the terminal and locate the dedicated time slots 
(random access) for logon request (9). 
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Figure 4.3: Initial forward link acquisition procedure 

After these following steps, the terminal is in the "Receive Sync State". That means it is ready to transmit its CSC burst 
in slotted aloha mode for logon (10). 

4.2.2.2.1 Network Information Table (NIT) 

As defined in EN 301 790 [1], the Network Information Table (NIT) describes the Transport Streams participating to a 
DVB Network (identified by its network_id), and carries information to find the RCS service_id and its related TS_id 
and satellite link parameters. The RCST is configured to tune to its start-up Transport Stream (TS), and locate the RMT 
from the NIT as follows: 

NIT header: The RCST selects the NIT (PID = 0x0010, tablejd = 0x40), containing the RSM-B networkjd. 

NIT loop-1 (series of descriptors): The RCST selects the linkage descriptor (descriptor_tag = 0x4A) dealing with the 
RCS Map service (linkage_type = 0x07). 

The RCST obtains the identifier of the transport stream carrying the RMT. 

The original_network_id shall be the RSM-B network. 

The RCST reads the servicejd assigned to the RCS Map service. 

The linkage descriptor dealing with RCS Map service is mandatory for the RCST, while others are 
ignored. The NIT shall contain only one linkage descriptor of this type. 
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The network name descriptor (descriptor_tag = 0x40) is mandatory and allowed only once. 

NIT loop-2 (array of TS): The RCST selects the element dealing with this TS_id found in RCS Map service linkage 
descriptor and witch The original_network_id corresponding to RSM-B network_id). 

NIT loop-3 (series of descriptors, internal to loop-2): The RCST extracts the satellite delivery descriptor 
(descriptor_tag = 0x43) and related parameters (frequency, orbital position, west_east_flag, polarization, modulation, 
symbol rate, FEC_inner). 

The satellite delivery descriptor is mandatory and allowed only once per loop-3, even when the RMT is always located 
in the start-up TS. 



NOTE: 



When the RCS TS is physically different from start-up TS, the RCST has to tune to it as soon as NIT 
processing is completed. 
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i orig_net_id = my_network_id 

i RCS_service_id 
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1 






satellite_delivery_descr 

frequency 

FECJnner 










: network_name_descriptor 































Figure 4.4: NIT: search for RMT 

4.2.2.2.2 RCS Map Table (RMT) 

The RMT (RCS Map Table), whose Table_ID is 0x41, describes transport streams tuning parameters to access to 
Forward Link Signaling services. It uses a linkage_descriptor identified by a linkage_type value of 0x81 (as defined in 
EN 301 790 [1]) that provides the association between one population_id and a set of parameters: 

• The original_network_id (equivalent to network_id). 

• The TS_id. 

• The service_id, which carries the PID of the ELS service. 

• The interactive_network_id (label that identifies the satellite network to which the table shall apply). 
Each TS_id tuning parameters are defined by the descriptors satellite forward link and satellite return link. 

4.2.2.2.3 Program Association Table (PAT) 

A Program Association Table, whose format refer to ISO/IEC 13818-1 [2] exists in each Transport Stream and carries 
the location (PMT_PID) of each program/service conveyed by this Transport Stream: 

• the NIT_PID fixed to 10 (Network_program_number 0). 

• the PMT_PID of the RMT, as defined in the NIT (TS acting as RCS TS). 

• the PMT_PID of the RCS FLS of the Interactive Network. 
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Each time access to a service is required, the RCST scans the PAT as follows to find relevant PMT: 

• PAT header: The RCST selects the PAT (PID = 0x0000, tablejd = 0x00) of its cuiTent TS. 

• PAT loop-1 (array of services): The RCST selects the service_id of targeted service (RCS service_id found in 
NIT, FLS servicejd found in RMT). 















PID = 0x0000 




▼ 1 






1 






program nr = 
N1T_PID=10 




tablejd = 0x00 

TS_id = my_nominal_TS_id 




1 






program nr = RCS service id 
PMT_pid_of_RMT 








1 










program_nr = FLS_service_id 
PMT_pidJor_FLS 

















Figure 4.5: PAT: Search for services and PIUIT PIDs 

4.2.2.2.4 FLS Program Map Table (PMT) 

The Forward Link Signaling service (FLS) conveyed by the Transport Stream, is described through the FLS -PMT 
which carries the PIDs of signaling tables. The PMT format shall refer to ISO/IEC 13818-1 [2]. 

The stream_type of FLS-PMT table is set to 0x05 (private section). 

The RCS_content_descriptor defines the following PID: 

• PID for PCR. 

• PID for: RMT, SPT, FCT, TCT corresponding to tablejd = 0x41, OxA3, OxAl, 0xA2. 

• PID for: SCT, coiTesponding to tablejd = OxAO. 

• PID for: CMT, TBTP, corresponding to tablejd = 0xA4, OxA5. 

• PID for: TIM_u/TIM_b, corresponding to tablejd = OxBO. 

4.2.2.2.5 Satellite Position Table (SPT) 

The SPT provides the RCST with the satellite ephemeris, to determine its emission instant, according to the distance 
between its own location and the satellite one. The SPT format shall refer to EN 300 421 (see bibliography). 

The satellite co-ordinates, periodically refreshed, are cartesian coordinates defined in meter in the geodetic reference 
frame ITRF96 (lERS Terrestrial Reference Frame), in line with the WGS84 (World Geodetic System 84) reference 
system at the one meter level. 
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Figure 4.6: SPT: Searchi satellite coordinates 
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The RCST extracts the SPT (PID found in PMT or by configuration, table_id = OxA3), and selects the section dealing 
with its interactive network. 

The RCST selects the element dealing with its satellite_id (provided in RMT) and extracts the satellite coordinates. 

4.2.2.2.6 Terminal Information Message broadcast (TIMb) 

TIM_b is a message broadcasted to all the RCSTs. It contains the "Network_status" and two descriptors, 
contention_control_descriptor and correction_control_descriptor given per superframe_id. 

The "Network status" of TIM messages are used to handle NCC restart and primary/back-up NCC switching. 

Table 4.1 : TIM b Network Status 



Parameter 


Size (bits) 


Value/Comment 


ID encrypt 


1 (msb) 


"0" 


Reserved 


1 


"0" 


Reserved 


1 


"0" 


CSC link failure 


1 


"0" 


Link_failure_recovery 


1 


"1" once the synchronization of the NCC is achieved , the 

bit "link_failure_recovery" and during a configurable 

timeout, so as to smooth the logon attempts and minimize 

collisions through increase of RCSTs CSC response time 

out. 

"0" after configurable timeout and forward link recovery 


Return link failure 


1 


"0" 


NCC receive failure 


1 


"0" 


Scheduler_Failure 


1 


"1" in case of primary NCC failure 
"0" no NCC failure 

When set to one, RCST shall suspend transmission of 
TRF burst, disable connection setup and internally release 
all traffic connections resources and flush buffers 
(meanwhile incoming traffic is discarded). It shall only 
maintain the control and management "connection" and 
the transmission of SYNC bursts with SAC field set to 0. 
The RCST shall wait for this bit to be set to to enable 
connection setup. 



4.2.2.2.7 Superframe/Frame/Timeslot Composition Table (SCT/FCT/TCT) 

SCT/FCT/TCT tables shall be compliant with RSM-B waveform described in TS 102 429-1 [3]. 

4.2.2.3 Logon procedure 

The logon procedure of the RCST is performed according to EN 301 790 [1] and is described hereafter. 
The logon procedures are basically distributed over the RCST and the NCC as follows: 

• RCST sends a logon request via CSC burst. 

• NCC checks if registration allowed and logon response is sent back to RCST in the TIM_u. 



RCST 



OBP 



NCC 



Logon req. ^ 


MPEG-2 TS Packet (CSC 
payload content, CSC burst 
measurements) ^ 


► 
^ 


Logon Resp (TIMu) 


^ 





Figure 4.7: Logon sequence 
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RCSTs support dynamic connectivity and are provided at log-on with a default signalling connection towards the NCC. 
Hence during log-on they signal this capability using the "dynamic connectivity" flag in the CSC burst defined in 
EN 301 790 [1]. 

Upon successful log-on the RCST receives the Return_CTRL_MNGM_PID which is used for control and management 
traffic towards the NCC (C2P signalling). 

4.2.2.3.1 RCST to NCC Logon request message (CSC burst) 

The logon procedure relies on the random emission of a CSC burst activated by the session control of the RCST. It may 
also result from an NCC activation through a wake-up message. 

The RCST is able to estimate the transmission window of the CSC bursts (Slotted Aloha mode) from the satellite 
positions contained within the SPT (Satellite Position Table) and its own location. 

Moreover, the RCST knows the CSC bursts position in the uplink MF-TDMA channel from the SCT (Superframe 
Composition Table), FCT (Frame Composition Table) and TCT (Timeslot Composition Table). This information has 
been acquired during the initial Synchronization procedure. 

A CSC burst payload contains the RCST MAC address and its capabilities (security, supported protocols, radio 
characteristics, ...). The CSC burst preamble is used for Synchronization and power estimation purposes. 

The terminals know the location of these CSC bursts thanks to the SCT, FCT and TCT. A CSC burst contains the 
terminal MAC address (physical address) and its capabilities (security, supported protocols, radio characteristics, ...). 

The CSC burst is defined as follows, compliantly with EN 301 790[1]: 



Reamble 


&icoded data 


FCSr Capability 
(24 bits) 


FCSr MAC @ 
(48 bits) 


CSC route id 
(1 6 bits) 


Dynamic 
connectivity (1 bit 


Freq hopping 
(1 bit) 


Fteserved 
(21 bits) 


Burst type 
id (1 bit) 




^ 




255 symbols 




80 


(TC= 4/5) symb 


3ls or 86 (TC= 3/4) symbols 







Figure 4.8: CSC burst format 

The RCST capability parameters are described in the table 4.2: 

Table 4.2: RCST capability field of CSC burst 



Capability parameter 


Size (bits) 


Value/Comment 


Security mechanism 


1 (msb) 


"0" (no security mechanism) 

"1" (security mechanism supported) 


SNMP 


1 


"1" (SNMP supported) 


ATM connectivity 


1 


"0" (Type A) 


IVIPEG-TS TRF 


1 


"1" (supports MPEG2 TRF) 


RCST boards 


2 


"00" (1 receiver) 


RCST ACQ 


1 


"0" (ACQ not required) 


MultiJDU 


1 


"0" (single IDU per ODU) 
"1" (several IDU per ODU) 


S/W Version 


8 


System dependent 


Frequency Hopping Range 


2 


"10" (36 MHz system dependent pattern) 


MF-TDMA 


1 


"0" (fixed MF-TDMA) 


RCST Class 


2 


System dependent 


Route ID capable 


1 


"0" (route ID not used) 


RCST Mode 


2 (Isb) 


"00": Installation mode 

"01": Operational mode 

"10": Reference RCST mode (measurements) 


NOTE: This table defines all the permitted values. Any values that are not listed above shall not be used. 
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Table 4.3: CSC burst data field parameters 



Parameter 


Size (bits) 


Value/Comment 


Preamble 


255 




RCST capability 


24 


See table 4.2 


RCST IVIAC address 


48 


RCST MAC address as per IEEE 802.3 


CSC Route ID 


16 


"0" (not used) 


Dynamic connectivity 


1 


"0" (supported) 


Frequency hopping 


1 


"1" (frequency hopping supported between adjacent slots) 


DVB-S capability 


1 


"1" (DVB-S capable) 


DVB-S2 capability 


2 


"11 "(DVB-S2 not capable) 


Reserved 


18 


Reserved 


Burst type identifier 


1 


"1" (identifies CSC burst) 


NOTE: This table defines all the permitted values. Any values that are not listed above shall not be used. 



CSC burst re-transmission is conditioned by the following fields of TIM_b Contention Control Descriptor: 

• CSC-response-timeout. 

• CSC-max-losses. 

• Max-time-before retry. 

The on-board Processor performs preamble estimations for each detected CSC burst and forward the CSC payload 
content with the measurements to the NCC through a specific MPEG-2 TS packet after translation into DULM 
Information Element. 

4.2.2.3.2 NCC to RCST Logon response message (TIM-u) 

Before answering to a CSC payload successfully received by the NCC, a phase of admission control consisting of 
checking the subscriber identification, the access rights and system resources availability is performed by the NCC. 

In case of admission, the reply is the unicast emission of a TIM_u by the NCC (using DSM-CC private section 
mechanisms). The TIM_u sections include the following information: 

• RCST status. 

• The Logon_Initialise_Descriptor that contains the Logon info : group_ID and logon_ID (logical address), 
MAC method, TRF burst type, and the Return CTRL_MNGM_PID for Connection Control Protocol (C2P) 
Messages. 

• The Return_TRF_PID is not used by the RCST. 

• The Correction_Message_Descriptor. 

• The S YNC_Assign_Descriptor provided by the resource control (assignment of ACQ is not applicable in 
RSM-B). 

The network_layer_information_descriptor. 

The GroupJD and Logon_ID sub-fields enable the NCC to identify the RCST that has transmitted a CSC burst in a 
contention timeslot. These are session parameters, and should remain valid during a logon session of the RCST. 

The Forward Link descriptor and the Return Link descriptor are transmitted within the RMT. 

The correction messages transmitted by the NCC contains frequency, time and power corrections to be applied on the 
next burst transmission, namely the first SYNC burst. To do this, the session control of the RCST extracts the 
Correction_Message_Descriptor of the received TIM_u and applies the corrections. 
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The contents of TIM-u descriptors of a successful logon are described in the following tables: 

Table 4.4: Logon initialize descriptor 



Parameter 


Size (bits) 


Value/Comment 


Reserved 


Information 


descriptor tag 




8 


0xA2 (as defined In table 29 of EN 301 790 [1] ) 


Descriptorjength 




8 


Number of bytes immediatly after descriptor length 
field 


group id 




8 


Assigned by the NCC 


logon id 




16 


Assigned by the NCC 


security tiandstial<e required 


3 




"0" 


prefix flag 






"0" 


data unit labelling flag 






"1" 


mini slot flag 






"0" 


contention based mini slot flag 






"0" 


capacity type flag 


1 




"0" 


traffic burst type 






"1" 


return TRF PID 




13 


"0" (not used) 


return_CTRL_MNGM_PID 


3 


13 


Assigned by the NCC (used for RCST to NCC 
connection control signaling messages) 


NOTE: This table defines all the permitted values. Any values that are not listed above shall not be used. 



Table 4.5: Sync assign descriptor 



Parameter 


Size (bits) 


Value/Comment 


Reserved 


Information 


descriptor tag 




8 


0xA4 (as defined in table 29 of EN 301 790 [1]) 


descriptor length 




8 


"00001010" (10 byte long) 


SYNC achieved time threshold 




8 


configurable parameter 


IVIax SYNC tries 




8 


configurable parameter 


SYNC achieved frequency thresh 
old 




16 


configurable parameter 


SYNC_start_superframe 




16 


current Superframe_counter plus the 
SYNC repeat period 


SYNC frame number 


3 


5 


configurable parameter 


SYNC repeat period 




16 


18 superframes 


SYNC slot number 


5 


11 


configurable parameter 


NOTE: This table defines all the permitted values. Any values that are not listed above shall not be used. 



Table 4.6: Correction message descriptor 



Parameter 


Size (bits) 


Value/Comment 


Reserved 


Information 


descriptor tag 




8 


OxAl (as defined in table 29 of EN 301 790 [1]) 


descriptor length 




8 


"00000101" (5 byte long) 


time correction flag 




1 


"1" 


power correction flag 




1 


"1" 


frequency correction flag 




1 


"1" 


slot type 2 bit field 




2 


"01" (CSC) 


burst time scaling 




3 


"100" 


burst time correction 




8 


Computed by NCC from burst time of arrival 
estimated by OBP (correction to be added by the 
RCST to previous value) 


power control flag 




1 


"0" 


Eb/NO 




7 


-lOlog (coding x ti) 2 x PNP, based on Power Phase 
Noise sent by OBP to NCC, with coding as defined 
for CI logon carriers 


frequency_correction 




16 


frequency error estimated by the OBP and formatted 
by the NCC (correction to be added by the RCST to 
previous value) 


NOTE: This table defines all the permitted values. Any values that are not listed above shall not be used. 
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Table 4.7: Network layer information descriptor 



Parameter 


Size (bits) 


Value/Comment 


Reserved 


Information 


descriptor tag 




8 


OxAF (as defined in table 29 of EN 301 790 [1]) 


descriptor length 




8 


depends on the message body 


message_body 






Formatted as an SNMP message, intended to 
perform RCST IVIIB update. It shall not exceed 255 
bytes and preferably fit within a single TS packet. It 
shall be formatted according to RFC 1901 [6] and 
RFC 1905 [7], and the PDU type shall be a 
SetRequestPDU. 



Table 4.8: Network layer information descriptor parameters 



Parameter 


Size (bits) 


Value/Comment 


Reserved 


Information 


PIDmmt 


3 


13 


PID Value dedicated for reception of MMT, as 
reserved per Group ID 


PIDtxMNGT 


3 


13 


PID value used to transmit SNMP messages to the 
NMC 


PIDrxMNGT 


3 


13 


PID value used by the RCST to receive management 
messages from the NMC 


IP_add_RCST_MNGT 




32 


management IP address of the RCST (air interface IP 
address) 


IP_add_NMC 




32 


The IP address of the NMC for SNMP trap sent by the 
RCST to the NMC 


IP subnet NMC 




32 


IP subnet of the NMC 


NMC_MAC_dest_MNGT 




48 


NMC Destination MAC address for RCST to transmit 
management messages 


CRAsig 




8 


Guaranteed capacity assigned to the Control and 
Management Signaling connection 


RBDC_max_sig 




8 


Maximum non guaranteed capacity assigned to the 
Control and Management Signaling connection 


NOTE 1 : When PIDtxMNGT is set to 0, the RCST shall not transmit any management messages on the air 
interface. 

NOTE 2: The message body of the NLID, according to EN 301 790 [1], shall be formatted as an SNMP 

message intended to the RCST MIB update process. It is formatted according to RFC 1901 and RFC 
1905, and the PDU type shall be a SetRequestPDU. Several Variable Bindings with objects defined 
in the RCST MIB may be included in the Variable Bindings list of NLID, depending capabilities of the 
RCST, and the services requested by the RCST. 



• When logon is rejected (Logon_fail_(busy) or Logon_denied set to "1"), the TIM-u shall include the 

Correction_message_descriptor()" with same format as for logoff except that slot_type field is set to "01" 
(CSC burst type). 

Once the TIM_u message is correctly received, the RCST is ready for fine Synchronization. 

4.2.2.4 Fine Synchronization procedure 

After the reception of a positive logon request, the Synchronization loop is started. The Synchronization is dealing with 
frequency, time and power control, namely the three items are synchronized within the same control loop. 

The SYNC bursts, allocated to the RCST through the TIM-u returned by the NCC, are transmitted on a dedicated 
segment of the uplink MF-TDMA channel as referenced in the SCT, FCT and TCT. 
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RCST 



OBP 



NCC 



^ 


r//Mu(' sync burst assignment) 


SYNC burst. ^ 


MPEG-2 TS Packet (aggregates 
of several SYNC payload 
content & measurements) ^ 


► 
^ 


GMT 


^ 





Figure 4.9: Fine Synchronization sequence 

The on-board Processor performs estimations on the preamble of each detected SYNC burst and forwards the SYNC 
payload content (SAC sub field : group/logon_id) with the measurements to the NCC through a specific MPEG-2 TS 
packet after translation into DULM Information Element. At packet reception, the NCC assembles, reformats and 
transmits the CMT. Then the frequency, time and power corrections to be applied to the next burst transmission till 
reaching the required accuracy are returned to the RCST. The different configuration parameters as e.g. loop-counts, 
timeouts and thresholds are specified in the SYNC Assign Descriptor as received via TIM_u and Correction Control 
Descriptor as received via TIM_b- 

The terminal extracts corrections to be applied from CMT and sends acknowledgement to NCC if corrections are within 
threshold Hmits (SAC field in Sync: M&C Message Def "Fine SYNC achieved"). 

Several successful correction cycles may be needed. This is pre-configured or set by management. The maximum 
number of Synchronization retries to achieve fine Synchronization is extracted from the SYNC Assign Descriptor 
contained within the TIM_u). 

If the corrections are within the threshold limits an acknowledgement is sent to NCC (SAC field in SYNC burst : M&C 
Message Def Fine sync achieved). 

After fine Synchronization achievement, the RCST is in "fine sync" state and can request resource for communication. 

4.2.2.4.1 RCST to NCC Synchronization message (SYNC burst) 

The SYNC message format and semantics shall be compliant with EN 301 790 [1]. The detail content of the SYNC 
burst should follow the description given in the TCT. 

4.2.2.4.2 NCC to RCST Synchronization message (CMT) 

The CMT, Correction Message Table, format and semantics shall be compliant with EN 301 790 [1]. 

A CMT section addresses several RCSTs through a loop feedback to a given number of correction messages. The CMT 
Table ID is 0xA4. 
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Table 4.9: CMT individual correction message descriptor 



Parameter 


Size (bits) 


Value/Comment 


Reserved 


Information 


group id 




8 


RCST identifier from SYNC burst payload 


logon id 




8 


RCST identifier from SYNC burst payload 


time correction flag 




1 


"1" or "0" (enable/disable time correction application) 


power_correction_flag 




1 


"1" or "0" (enable/disable power correction 
application) 


frequency_correction_flag 




1 


"1" or "0" (enable/disable frequency correction 
application) 


slot type 




2 


"11" (sync) 


burst time scaling 




3 


"100" 


burst_time_correction 




8 


computed by NCC from burst time of arrival 
estimated by OBP (correction to be added by the 
RCST to previous value) 


power control flag 




1 


"0" (Eb/NO) 


Eb/No 




7 


-1 log (coding x ji ) - 2 x PNP, based on Power 
Phase Noise returned by OBP to NCC 


frequency_correction 




16 


frequency error estimated by OBP and formatted by 
the NCC (correction to be added by the RCST to 
previous value) 


NOTE: This table defines all the permitted values. Any values that are not listed above shall not be used. 



NOTE: Time, power and frequency corrections flags allow to enable (value 1) or disable (value 0) the application 
of corrections according to timing, power and frequency correction enable/disable parameters configured 
in the MIB (logical AND). 

4.2.2.5 Synchronization Maintenance procedure 

During all the communication session (from fine Synchronization achievement until logoff), the maintenance of 
Synchronization is ensured via the periodic transmission of SYNC bursts by the RCST, according to the allocation 
notified by the NCC at logon. 

The process, based on SYNC burst transmission and CMT correction reply, is similar to the fine Synchronization 
procedure, with a periodicity defined in the section devoted to physical layer definition. 

4.2.2.6 Log-off procedure 

The logoff is normally initiated by the RCST (although other triggers are also possible) and the logoff request is sent to 
the NCC in the SAC sub-field: M&C Message Definition set to 0x0002. 

On reception, the NCC releases all the related RCST resources (SYNC burst, logical address and parameters). The NCC 
returns no confirmation. 

The RCST goes to the "Stand-by" state (FLS must be re-acquired). 

4.2.2.6.1 Logoff sequence and timing 

The RCST activates its logoff procedure as result of the following conditions: 

• Upon NCC request (TIM-u logoff message). 

• Upon end-user request. 

The RCST must send a SYNC SAC field to notify its logoff without transmitting any connection release message. 
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RCST 



OBP NCC 

Logoff Request (TIMu) 



Loaoff Indication (SAC ) 



Figure 4.10: Logoff sequence 

After reception of a logoff request: 

• The NCC releases all the related RCST resources. 

• No confirmation is sent back by NCC. 

• The RCST goes back to "Receive Sync State" (unless power down). 

4.2.2.6.2 Logoff message 

TIM-u parameters and descriptors format shall be compliant with EN 301 790 [1]. The TIM-u Table_ID is OxBO. 

Table 4.10: Logoff message RCST Status 



Parameter 


Size (bits) 


Value/Comment 


Reserved 


Information 


ID encrypt 




1 (msb) 


"0" (no TBTP logon ID encryption) 


Logon fail (busy) 




1 


"0" 


Logon denied 




1 


"0" 


Log off 




1 


"1" (logoff notification from NCC) 


Transmit_Disable 




1 


"0": Transmission authorized 

"1": RCST shall cease transmission and enter hold 

mode till an uni-cast TIM resets this bit to "0" 


Rain Fade release 




1 


"0" (no rain fade reconfiguration procedure) 


Rain Fade detect 




1 


"0" (no rain fade reconfiguration procedure) 


Wake up 




1 (Isb) 


"0" (no wake-up notification from NCC) 


NOTE: This table defines all the permitted values. Any values that are not listed above shall not be used. 



Descriptor_loop_count: set to (1 descriptor), detailed in table 4.11: 



Table 4.11 : Logoff message correction message descriptor 



Parameter 


Size (bits) 


Value/Comment 


Reserved 


Information 


descriptor tag 




8 


OxA1 as defined in table 29 of EN 301 790 [1] 


descriptor length 




8 


"00000001" (1 byte long) 


time correction flag 




1 


"0" 


power correction flag 




1 


"0" 


frequency correction flag 




1 


"0" 


slot type 2 bit field 




2 


"11 "(SYNC) 


burst time scaling 




3 


"000" 


burst time correction 







none 


power control flag 







none 


Eb/NO 







none 


frequency correction 







none 


NOTE: This table defines all the permitted values. Any values that are not listed above shall not be used. 
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4.2.2.7 Hold mode procedure 

The hold mode procedure of the RCST is performed according to EN 301 790 [1] and is described hereafter. 

When receiving a TIM-u whose "transmit_disable" flag is set to "1", the RCST shall cease transmission and enter the 
hold state whatever is its current state. Only Forward Link Signalling (FLS) acquisition and NCR Synchronization are 
maintained in "Hold mode" state. It remains in the hold state and cannot transmit till reception of a TIM-u message with 
the "transmit_disable" flag is set to "0". In case of power off or reset in the "Hold mode" state, the RCST goes back to 
the "Hold mode" state after initial Synchronization procedure. 

The TIM-u content for hold mode notification is the same as for logoff message (see clause 4.2.2.6.2 ) except for the 
"RCST status" field defined in table 4.12: 

Table 4.12: Hold mode TIM-u message RCST Status 



Parameter 


Size (bits) 


Value/Comment 


Reserved 


Information 


ID encrypt 




1 (msb) 


"0" (no TBTP logon ID encryption) 


Logon fail (busy) 




1 


"0" 


Logon denied 




1 


"0" 


Log off 




1 


"0" 


Transmit Disable 




1 


"1" (Transmission inhibited) 


Rain Fade release 




1 


"0" (no rain fade reconfiguration procedure) 


Rain Fade detect 




1 


"0" (no rain fade reconfiguration procedure) 


Wake up 




1 (Isb) 


"0" (no wake-up notification from NCC) 


NOTE: This table defines all the permitted values. Any values that are not listed above shall not be used. 



The RCST shall exit from hold state and enter the logon procedure when receiving a wake-up message. 

The RCST shall exit from hold state and enter "receive sync" state with all "RCST status" flags set to "0", in which case 
it shall further receive a wake-up message to enter the logon procedure. 

In any case, the TIM-u only includes the "correction_message_descriptor()", with correction flags set to"0" as for 
logoff. 

4.2.2.8 Wake Up procedure 

The wake up procedure of the RCST is performed according to EN 301 790 [1] and is described hereafter. 

When receiving a TIM-u whose "wake-up" flag is set to "1", the RCST shall enter the logon procedure. 

The TIM-u content is the same as for logoff message (see clause 4.2.2.6.2) except for the "RCST status" field defined in 
table 4.13: 

Table 4.13: Wake Up TIM-u message RCST Status 



Parameter 


Size (bits) 


Value/Comment 


Reserved 


Information 


ID encrypt 




1 (msb) 


"0" (no TBTP logon ID encryption) 


Logon fail (busy) 




1 


"0" 


Logon denied 




1 


"0" 


Log off 




1 


"0" 


Transmit Disable 




1 


"0" (Transmission authorized) 


Rain Fade release 




1 


"0" (no rain fade reconfiguration procedure) 


Rain Fade detect 




1 


"0" (no rain fade reconfiguration procedure) 


Wake up 




1 (Isb) 


"1" (wake-up notification from NCC) 


NOTE: This table defines all the permitted values. Any values that are not listed above shall not be used. 



The TIM-u only includes the "correction_message_descriptor()"as for logoff (see clause 4.2.2.6.2). 



£75/ 



27 ETSI TS 102 429-2 V1.1.1 (2006-10) 

NOTE: The RC ST shall restart the initial Synchronization procedure to enter into the "Receive sync" or "Hold 
mode" state (according to tx_disable flag value) in the following cases: 

Logoff procedure initiated by the NCC. 

Logon_fail_(busy} notified by the NCC. 

Logon_denied notified by the NCC (with transmit_disable flag set to 1). 

NCR not received for configurable consecutive seconds. 

Fine Synchronization not achieved after configurable consecutive SYNC attempts. 

Logon TIM_u not received after configurable consecutive CSC attempts. 

CMT burst correction not received after configurable consecutive SYNCs. 

4.3 Resource Control 

4.3.1 Overview 

The RSM-B resource control is based on the timeslot allocation procedure as defined in EN 301 790 [1]. Burst time 
composition plan is defined thanks to the BTP tables: SCT, FCT and TCT. Terminal burst time assignment is given by 
the TBTP table. 

4.3.2 Definitions 
4.3.2.1 Signalling definitions 

This clause presents the messages exchanged between the RCSTs and the NCC in the resource control context defined 
in RSM-B, in line with EN 301 790 [1]. 

4.3.2.1 .1 Forward link signalling from NCC to RCST: TBTP (Terminal Burst Time Plan) 

The TBTP defines the dynamic timeslot assignment generated every superframe. The RCST uses the SCT, FCT and 
TCT to know the organization of the uplink MF-TDMA channels, and particularly the superframe, frame, and timeslot 
number. In the TBTP, in association with the absolute date (in PCR count) these references are used by the RCST to 
identify to which the allocation applies. 

There is one TBTP section per group_id and per downlink containing the following information: 

• The group_id. 

• The superframe_count (modulo 216) set by the NCC to its current value plus an integer number of 
superframes, taking into account 2 superframes for RCST reception and processing. The RCST shall be able to 
process a TBTP received at frame (n) to locate all its assigned bursts before end of frame (n+1), so as to apply 
it at frame (n+2), with respect to the superframe counter notified in the TBTP. 

• The list of timeslots allocated to RCST per channel_id. 

The burst allocation reference used by the RCST is given by the superframe start time and duration, which are updated 
and notified by the NCC through the SCT. Knowing the superframe_start_time associated to a superframe_count, the 
RCST is able to retrieve the exact location of its assigned bursts through application of the time and frequency offsets 
extracted from the FCT and SCT. 

Moreover, for burst transmission, the RCST anticipate the time assigned in the TBTP so as to take into account the shift 
of its local Network Clock Reference (D/L propagation delay) and the burst transmission delay (U/L propagation 
delay). 
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The RCST retrieves the transmission time of its assigned burst through the following steps: 

1) At TBTP reception, the RCST extracts from the section corresponding to its Group_id: 

The superframe_count to which the TBTP is attached. 

The frame number and the slot number corresponding to its Logon_id. 

2) The RCST extracts from the previously received SCT: 

The superframe_start_time attached to a superframe_counter. 

The superframe_duration. 

The frame_start_time, the frame_center_frequency offsets and the frame_id corresponding to the 
frame_number notified in the TBTP. 

3) From the FCT, the RCST retrieves the description of relevant frame_id, i.e. timeslot_time_offset, 
timeslot_frequency_offset and timeslot_id (slot type) for allocated timeslot. 

4) From the TCT, the RCST extracts information about relevant timeslot_id: 

The burst_start_offset. 

The timeslot transmission structure plus some access flag. 

5) The RCST can then deduce the transmission time, in PCR counts, of its assigned burst, from: 

The SCT superframe_start_time. 

The difference between TBTP and SCT superframe_counter, multiplied by the superframe_duration. 

The frame, timeslot and burst time and frequency offsets. 

The uplink and downlink transmission delay (computed at logon owing to SPT and RCST position, and 
periodically adjusted owing to returned CMT). 

6) This value is compared to the current reconstructed NCR to activate burst transmission. 
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The figure below summarizes the process for burst transmission time retrieval and the required parameters stored in the 
RCST memory or extracted fi*om the signalling tables: 
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Figure 4.11 : Timeslots allocation process 

The TBTP processing can be summarized in the following procedure: 

1) Analysis of TBTP section header (SI private section header): 

The RCST extracts the TBTP (PID found in FLS-PMT, tablejd = OxA5). 

2) Analysis of TBTP section: the RCST checks its interactive network. 
If the section corresponds to its group identifier: 

The RCST reads the superframe count to which the BTP applies. 
The RCST searches all occurrences of its logon_id. 

The RCST reads the parameters describing the block of timeslots allocated to it. 
Else: 

Skip to the next section. 
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PID = FLS_TBTP_pid 



table id = 0xA5 



IN_id = myJNJd 



groupjd = mygroupjd 

superframe_count 

frame_loop_count 



frame_number 
BTP_loop_count 



logonjd = myjogonjd 2 
multiple_channels_flag 
assignment_type 
start_slot 

IF flag = I ; channeUd 
assignment_count 



Figure 4.12: Description of timeslots assignment in TBTP 

The RCST shall be able to process a TBTP to be applied up to 16 superframe later, with respect to the superframe 
counter notified in the TBTP. 

4.3.2.1 .2 Return signalling from RCST to NCC: SAC field (SYNC burst) 

For the resource control, the SAC field is used for capacity request for dynamic allocation. In RSM-B, several capacity 
requests may be contained within the SAC field. 

The request computation process is memory-less in the RCST, i.e. when computing a request the RCST does not take 
into account the previous request correlated with capacity allocation. 

4.3.2.2 Capacity request categories definition 

The resource control in RSM-B combines three baseline DVB-RCS capacity categories: 

• Continuos Rate Assignment (CRA). 

• Rate-based Dynamic Capacity (RBDC). 

• Volume-based Dynamic Capacity (VBDC). 

• Free Capacity Assignment (FCA). 

CRA: This capacity is allocated without a capacity request being sent by a terminal. This capacity is guaranteed. The 
granularity is based on the rate of the TRF_burst mapped on a given carrier and depends on its coding rule 4/5 or 3/4. 

RBDC: Rate capacity, dynamically requested by terminals on a per channel_id basis through the SAC field of the 
SYNC burst, and fairly shared between terminals. Each request overrides any previous one from the same terminal. A 
request is subject to a time-out mechanism and a maximum rate parameter (set in RCST profile). 

VBDC: Volume capacity, dynamically requested by terminals on a per channel_id basis through the SAC field of the 
SYNC burst, and fairly shared between terminals. Each request overrides any previous one from the same terminal. A 
request is subject to a time-out mechanism and a maximum rate parameter (set in RCST profile). 

FCA: Automatically assigned to a terminal according to its profile from unused capacity without any request. The 
availability of this bonus capacity per channel_id is highly variable and just aims at reducing delays on any traffic, 
which can tolerate delay jitter. 

The RCST supports dynamic radio resources control function, also referred to as DAMA (Demand Assignment 
Multiple Access) agent. It is assumed that the RCST is able to perform fast frequency hopping in at least a 36 Mhz 
MF-TDMA channel. 
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4.4 Connection control 



The Connection Control Protocol (C2P), describes the mechanisms and messages required for the acceptance, the 
establishment, the modification and the release of connections. Full details of the protocol are described in 
TS 102 429-3 (see bibliography). 

4.4.1 Definitions 

4.4.1.1 Connection 

A connection is defined as the means to propagate packets (traffic or signaling) with the same priority from one RSM-B 
network reference point to one (unicast) or more (multicast or broadcast) distant RSM-B network reference points. 
These RSM-B network reference point correspond to RSM-B RCSTs or RSGWs. 

Between two RCSTs/RSGWs there can be as many connections as different priority levels are defined in the System. In 
RSM-B system there are 4 different levels of priority. Therefore for RSM-B system a maximum of 4 connections may 
be estabhshed between two RCSTs/RSGWs. 

Each connection is identified thanks to a connection_reference_id. This identifier allows each RCST/RSGW to locally 
identify all the active connections present. 

The Connection Control Protocol (C2P) "IE" (Information Element) fields allow to associate various attributes to the 
connection according to end user service needs. 

4.4.1.2 IP flow 

A connection may carry one or several unitary IP flows. Each RCST will be capable of identifying IP flows thanks to a 
multifield classification. 

EXAMPLE: An IP flow may be identified in terms of IP source and destination addresses, DSCP value, 
protocol type and source and destination port numbers. 

The multifield filtering criteria is configured thanks to a Type of Flow table on each RCST. 

4.4.1.3 Channel 

Channel is the logical access link between an RCST and all its destination RCSTs sharing the same beam. A Channel is 
associated to a physical route and to a specific MF-TDMA uplink resource through the TBTP. 

It is possible to map either a single or N connections to one Channel depending on quality of service and routing 
considerations. The whole capacity allocated per channel is shared between all the connections established on this 
channel. 

Each channel is identified thanks to a ChannelJD. 

4.4.1.4 Stream 

RSM-B system is based on the MPEG-2 TS profile of EN 301 790 [1]. Therefore each connection will be identified in 
terms of MPEG-2 TS stream identifiers. 

In case of a bidirectional connection, two stream identifiers would uniquely identify the transmission and the reception 
of traffic. In case of a unidirectional connection, only one stream identifier is required to identify the transmission or the 
reception of traffic. 

These stream identifiers are also called PIDs, Program IDentifier, following MPEG2 TS nomenclature. 

As a summary, the following figure represents the relationship between all previous identifiers: connection, stream, 
channel, and spot beams. 
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Figure 4.13 illustrates a typical arrangement of unicast connections from one RCST-A attached to one single sub-net 
transmitting traffic towards the TDM 1 : 

• a high priority connection towards RCST3 is identified by (ch_lD-l, PID A-1 HP, MAC address RCST3); 

• a low priority connection towards RCST2 is identified by (ch_lD-l, FID A-1 LP, MAC address RCST2). 



IP FLOW IS CLASSIFIED AND 

MAPPED ON THE 
CONVENIENT CONNECTION 



Best Bfort Service 
(Low Priority 



RCST A : SOURCE 



Guaranteed Data 
Rate Service 
(High Priority) 



CONNECTIONS CLASSIFIED PER PRIORITY 
AND AGGREGATED PER CHANNEL ID 




To RCST 3 
(MPE MAC@ 3) 




Figure 4.13: Connection, cliannelJD and PIDs arrangement 

4.4.1.5 Connection type 

Signaling (control and management) connections are differentiated from user data traffic connections. 

4.4.1.5.1 Signalling connections 

The communication between the MS (NCCandNMC) and the RCSTs is done thanks to signaling connections. This 
signaling connection may convey only control and management information. 

Signalling connections are implicitly opened at terminal logon without the need of C2P messages. Therefore no real 
connection_reference_lD are assigned to them. All the information required for a signaling connection is contained in 
the logon messages received by the RCST. 

Signalling connections are required to send: 

• C2P control message to the NCC; 

• management SNMP messages to the NMC. 

Each connection will have different PID values for transmission and reception assigned thanks to the logon messages. 

Different internal queue buffers will be assigned to each signaling connection in the RCST. Both connections will share 
the timeslots allocated on the reserved signaling channel_lD 0. 

These connections correspond to the control and management plane of the RCST. 

4.4.1.5.2 Traffic connection 

These are mesh or star, bi-directional or uni-directional, unicast or multicast between two or more terminals (RCST or 
RSGW) and belong to the User Plane of the RCST. Traffic connection setup is based on the exchange of C2P between 
RCST/RSGW and the NCC. 
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4.4.1 .5.2.1 Permanent and on_demand connections 
Traffic connections may be established, or released : 

• by management (NMC) initiated by the NCC: permanent connections; 

• on-demand, initiated by the RCST (GW_RCST). 

Permanent connection: Established upon NMC initiative when peer terminals are synchronized. Permanent connection 
establishment and release procedures are performed using the C2P protocol [AD5]. C2P permanent connection 
establishment/release is initiated by the NCC Connection Control function (when indicated from the NMC) and never 
released by terminals. 

On-demand connection: Established upon explicit request from the RCST or RSGW. On-demand connection 
establishment and release procedures are performed using the C2P protocol [ADS] and are initiated by the RCST or 
RSGW Connection Control function. 

4.4.1 .5.2.2 Star and mesh connections 

Traffic connections are differentiated depending if it involves a RSGW or not. 
Star connection: Connection established between a RSGW and a RCST. 
Mesh connection: Connection established between two user RCSTs. 



Star connection isp Server 
Internet 




signalling 



Figure 4.14: Star and IVIesh connections 



4.4.2 Signalling messages 

This clause recalls the major messages exchanged between the RCSTs and the NCC in the connection control context. 
How this messages are build and exact details of the parameters used are described in TS 102 429-3 (see bibliography). 

4.4.2.1 Forward link signalling from NCC to RCST: TIM 

TIM_u, is the Individual Terminal Information Message message used by the NCC to transmit the Connection Control 
Protocol (C2P) messages towards the RCST. It is sent in DSM-CC (Digital Storage Media Command and Control) 
private section, using the RCST MAC address. 
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4.4.2.2 Return link signalling from RCST to NCC: DULM 

The DULM Packet- Data Unit Labelling Method, is a message-based method that allows RCSTs to transmit the 
Connection Control Protocol (C2P) Messages towards the NCC. The Return_CTRL_MNGM_PID is used in the header 
of the DULM packet. DULM packet payload is constructed starting by the Group_id and Log-on_id and followed by 
the connection control lEs. 

4.4.3 Major C2P attributes 
4.4.3.1 Connection profile parameters 

C2P connection profile parameters parameters are handled by the connection control and interpreted by the resource 
control to map a convenient allocation mode and resource to the connection. 

These parameters are summarized in table 4.14: 

Table 4.14: C2P connection profile parameters 



C2P profile parameters 


Description 


SDR 


Sustainable data rate expected by tlie connection 
IVIapped on CRA: Guaranteed capacity > 


PDR 


Peal< Data Rate, maximum data rate supported by the connection 
IVIapped on RBDC: Un-guaranteed capacity > based on Capacity 
request 


Priority 


Priority class: 

- Low Priority (LP): best effort 

- High Priority (HP): real time non-jitter sensitive 

- High Priority with jitter constraints (HPj): real time traffic with jitter 
constraints (typically VoIP) 

- Streaming priority (SP) 



4.4.3.2 Capacity Request mapping 

The Resource Control is in close interaction with the connection control. The RCST radio resource control updates the 
channel information each time a connection is set up, modified or released. 

For each RCST in the RSM-B network the following capacity categories are configured at NMC level: 

Table 4.15: Capacity Categories 



Capacity category 


Description 


CRA_sig 


Average constant data rate (>0) for RCST to NCC control 
signalling (C2P messages) and RCST to NIVIC management 
signalling (SNMP messages). 


CRAstarmax 


Maximum guaranteed data rate (>0) for star connections 
Allocable in dynamic mode. 


CRA_mesh_max 


Maximum guaranteed data rate (>0) for mesh connection 
Allocable in dynamic mode. 


RBDC_star_max 


Maximum data rate (>0) for all star connections allocable in 
dynamic mode in response of Capacity Request (CR) sent by 
the RCST. 


RBDC_mesh_max 


Maximum data rate (>0) for all mesh connections allocable in 
dynamic rate in response of CR sent by the RCST. 


VBDC_star_max 


Maximum volume rate (>0) for all star connections allocable in 
dynamic mode in response of Capacity Request (CR) sent by 
the RCST. 


VBDC_mesh_max 


Maximum data rate (>0) for all mesh connections allocable in 
dynamic rate in response of CR sent by the RCST. 


FCA_enabled 


If set, the free capacity available on a given uplink is fairly 
distributed between RCSTs in dynamic mode and between 
channel id mapped on the uplink on which the RCST belongs 
to. 
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4.4.4 Functional mapping 



The Resource control is in close interaction with the Connection control. After classification of incoming IP flows by 
the interworking functions, the MPE encapsulation and the MPEG-2 segmentation, the resource control function is 
responsible for the distribution of the assigned capacity between the different buffers per channel and requesting the 
extra capacity if needed. 

NOTE: Traffic queuing may be done on IP, MPE or MPEG level depending on the RCST implementation. 

The RCST resource and connection control functional architecture is presented in figure 4.15: 
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Figure 4.15: RCST: resource and connection control functional architecture 

There may be various channel_id dedicated to star/mesh traffic. The figure represents only two channel_id for mesh 
traffic (traffic between RCSTs), and one channel for star traffic (traffic between an RCST and the RSGW). 

According to the configuration, the RCST resource and connection control functional architecture includes: 

• One queue buffer per connection. Each connection queue buffer will be assigned to a certain channelJD. 

• Zero or more connection queue buffer(s) per channelJD. The maximum number of connection queue buffers 
per channel is given by the maximum number of traffic classes defined. For RSM-B, four different priority 
levels are defined. 

• A control signalling process in charge of the C2P communication between the RCST and the NCC. This 
process that generatesC2P messages and forwards it to the dedicated HP (High Priority) queue buffer of 
channel_id 0. 

• A management signaling process in charge of the snmp communication between the RCST and the NMC. This 
process generates the snmp responses forwarded through the LP queue buffer of channelJD 0. 

• A minimum signalling bandwidth capacity in terms of CRA_sig is automatically allocated by the NCC on 
channeljd without generating initial request from the RCST. However, more capacity on this channel can be 
requested by the RCST via the conventional capacity request scheme. Management messages use also this 
channeljd (LP buffer). 
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A classifier or interworking interface, that allows to forward IP datagrams to the right connection queue buffer. 

A scheduling mechanism between all the connection queue buffers per channel. The scheduling will mark 
which packet should be forwarded first towards the channel buffer and transmitted through the air interface. 
This means that it multiplexes together packets coming from the different connection queue buffers assigned 
to the same channel_ID. Possible scheduling mechanism are strict priority, token bucket or weight fair 
queuing. 

An access control process to manage the way data is transmitted towards the physical layer. This process 
regularly receives TBTP messages from the RCST's forward link reception. These messages describe the 
frequency/time windows on which the RCST is allowed to transmit its allocated timeslots. From the TBTPs, 
the Access Control knows per channel_id the slots to be used. 

The connection queue buffers handle IP packets. The MPE segmentation and encapsulation is done afterwards. 
Interleaving must be assure. 



4.4.5 Connection Control functions 

The RCST connection control function shall support two activation modes: 

• permanent connection establishment by the NCC at pre-defined date and time marked from the NMC; 

• on-demand connection established on request from the RCST/RSGW. 

NOTE: The connection control functions defined in the following sections, apply to any RCST present in the 
RSM-B network, not only to user RCST but also to GW_RCST (as part of the RSGW). Only when is 
needed, special distinction is made for star or mesh scenarios, as it is case for multicast. 

4.4.5.1 On-demand connection control 

The RCST shall support the following connection control processes for on-demand connections: 

• connection establishment; 

• connection release; 

• channel modify. 

4.4.5.1 .1 On-demand connection establishment 

4.4.5.1.1.1 Galling RCST 

The RCST shall send a new connection establishment upon detection of an IP flow: 

• when the destination IP address in the IP header matches a routing entry (static entries); 

• and there is no already open connection with the same priority class than the one of the detected IP flow. 

The C2P connection establishment request will carry the source and destination IP address of the initiator IP packet, the 
C2P parameters attached to the IP type of flow obtained through classification of the packet and the 
connection_reference_id. When initiating a connection request, the RCST sets itself the connection reference field of 
the C2P message to be sent to the NCC. 

This request is transmitted towards the NCC through the control signaling connection. 

NOTE: One RCST may have several pending connection setup. This is limited to the maximum number of 
priority levels defined in the system. For RSM-B this number is four. 

The RCST should then wait for the C2P Connection Establishment Response sent by the NCC. 
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In case of positive connection establishment, the RCST extracts the destination prefixes and connection parameters as 
the transmission and reception profiles and PIDs from the response message. It will update the routing table (dynamic 
entries) with the received destination prefixes not yet existing, will attach the connection parameters to relevant entries 
in an active connection database, and associate the cnx_ref_id to the connection queue buffer. 

In case of negative connection establishment response, the RCST shall drop the corresponding pending request and 
initiator IP packet and wait an inhibition timeout before retrying to establish a connection with the same level of 
priority. 

In case of C2P Connection Establishment Request time-out, the RCST could retry to send a new request up to a 
maximum of C2P Maximum number of retries. Once this maximum is reached the RCST shall drop the corresponding 
pending request and initiator IP packet and wait an inhibition timeout before retrying to establish a connection with the 
same level of priority. 
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Figure 4.16: Establishment request procedure for on-demand C2P connection with priority P1 
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4.4.5.1.1.2 



Called RCST 



As a called RCST , it will receive a C2P Connection Establishment Request message. The RCST will process the 
content of the message. 

• If the connection is accepted, the RCST shall respond with a C2P Connection Establishment Response 
Successful and extract the destination prefixes and connection parameters. The RCST then updates the routing 
table (dynamic entries) with the received destination prefixes not yet existing, and will attach the connection 
parameters to relevant entries in an active connection data base. 

• If the connection cannot be rejected, the called RCST will answer with a C2P Connection Establishment 
Response Reject, including the cause of the rejection. 

NOTE: In case an RCST, that has already established a unidirectional connection with another RCST, receives a 
request for a bidirectional connection towards the same RCST, it should first release the unidirectional 
connection, and then accept the establishment of the bidirectional connection. 

4.4.5.1 .2 On-demand connection release 

On-demand connections have activity timers associated to them. The activity timer is restarted every time there is 
activity on the connection. In case of a bi-directional connection every time there is traffic either transmitted or 
received. If the timers associated to a connection expire, the corresponding connection is released. The calling or called 
RCST will send a connection release request for this connection. This way the RCST informs the NCC which removes 
all the resources associated at this connection. 

At reception of connection release response, the RCST removes the related connection parameters and the relevant 
routing entries will be no longer attached to any connection. The RCST shall then release all the relevant resources and 
flush the associated connection queue buffer buffer no longer used. 

It is also possible to release on-demand connection by local management from the user interface or by request from the 
NCC. 
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Figure 4.17: On-demand C2P cnx release request procedure from calling RCST 
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Figure 4.18: On-demand star connection scenario 
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Figure 4.19: On-demand meshi connection scenario On-demand connections channel modify 
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The aim of the channel modify mechanism is to allow an RCST to ask for modification of the guaranteed capacity 
allocated to one channel. This extra capacity is relative to the status of all the connection queue buffers associated to 
this channel and should not exceed a certain maximum defined in their profiles. 

At connection set-up a certain amount of guaranteed capacity is requested. This value is given in the connection profile 
parameters. If the connection is successfully established, this guaranteed capacity will be provided and allocated in the 
TBTP. 

For each channel_id, the individual data queue buffer per connection has a configurable high and low watermark 
relative to the guaranteed capacity authorized for the considered RCST. 

Allocation of additional guaranteed capacity per channel can be provided upon channel_modify requests initiated by the 
RCST . Such capacity request is activated if the number of IP packets in the connection queue buffer rises above a 
configured threshold value (high watermark). 

If the already extra capacity requested has not exceeded a certain maximum of capacity defined by the connection's 
profile, a C2P message Channel modify request will be sent towards the NCC requesting this additional capacity. 

A dual mechanism is implanted to detect if the connection queue buffer does not more utilize its additional assigned 
capacity, namely when the number of IP packets cross a low threshold in the decreasing direction (low watermark). 
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Figure 4.20: Channel modify mechanism 

These both high and low watermarks must be distinct for hysteresis purposes. The associated values (threshold and 
timer) are set in the subscriber profile and the guaranteed capacity is allocated up to the limit defined by the global SDR 
as set in the RCST profile. 
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Figure 4.21 : Ondemand Channel Modify procedure 

4.4.5.2 Permanent connection control 

The establishment of permanent connections will be controlled and initiated by the NCC as configured by management 
in the NMC. Permanent connections may be star or mesh, unicast or multicast. 

In case of unicast permanent connection, the connection becomes effective only if the two involved parties are logged 
and in fine sync state. 

For permanent multicast, only the transmitting RCST is involved in the connection establishment/release process. The 
NCC updates the MMT in order to inform the other RCSTs and RSGWs in the satellite network willing to receive the 
multicast flow. 
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4.4.5.2.1 Permanent connection establishment 

At reception of a C2P connection establishment request NCC initiated, the RCST will process the content of the 
messages, extract the destination prefixes and connection parameters, update the routing table and store the connection 
parameters as for an on-demand connection. The RCST will disable the activity timers of permanent connections. The 
RCSTs (or RSGW) involved in a permanent connection are considered as called parties. 

NOTE: It may be possible to receive a permanent connection estabUshment request with the same parameters 

(same called parties and with the same priority level) as an already created on-demand connection. In this 
case, the connection should be accepted, and the traffic forwarded by the permanent connection. The 
on-demand connection will then be released thanks to timeout of activity timers. 

4.4.5.2.2 Permanent connection release 

The permanent connection lifetime is fully controlled by the NCC. Therefore the release of a permanent connection 
may only be initiated by the NCC as configured in the NMC. 

At reception of a connection release from the NCC, the RCST shall send a connection release response, remove related 
connection parameters and relevant routing entries no longer attached to any connection. The RCST should also release 
all relevant resources and flush the associated connection queue packet buffer no longer used. 
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Figure 4.22: Permanent star connection scenario 
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Figure 4.23: Permanent mesh connection scenario 

4.4.5.2.3 Permanent connection channel modify 

For permanent connections, a daily profile can be defined allowing to vary the bandwidth parameters of the connection 
according to the period of the day. The channel modify procedure may affect one or several permanent connections per 
channel_id. In this case the NCC sends a channel_modify request to the involved parties at given time of the day as 
foreseen by the connection profile. 



Quality of Service 



The Network layer QoS may be defined as a probability of fully satisfying the QoS required by each user IP flow. The 
Network layer QoS depends on the traffic profile of the whole RSM-B system and the traffic profile of the RCST. The 
Network layer QoS figures can be defined only when these traffic profiles are agreed. The Network layer QoS 
mechanisms consist in performing prioritization of IP flows and asking the SLC layer for the most suitable transmission 
parameters for the considered application. 

These mechanisms aim to provide priority to mission-critical data transactions or video or voice transmissions which 
require faster turnaround while providing service to less time - sensitive traffic (like e-mail o web surfing). 

QoS on RCST level is based on adapting the satellite connection parameters to what the appUcation requires. This 
requires identifying each application type and managing each of the application flows. 

The QoS mechanisms on the RCST are based on traffic differentiation. The RCST is capable of classifying IP traffic 
into several IP flows. Each IP flow is identified thanks to a multifield filter definition. The queuing and scheduling 
between IP flows depends on the QoS strategy defined within the RCST. 
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5.1 



Traffic classes 



RSM-B is able to support the following traffic categories: 

• Best effort or Low Priority (LP): Used by applications that to not have specific delay and jitter constraints. 
This traffic receives the lowest priority in the transmission scheduler of the terminal. A token bucket or WFQ 
algorithm is used in order to avoid that this queue gets blocked by real time non-jitter sensitive traffic queue. 

• Real time non-jitter sensitive or High Priority (HP): Used by applications sensitive to delay but not to jitter. 
This traffic receives the highest priority in the transmission scheduler of the terminal. 

• Real time jitter sensitive or High Priority with jitter constraints (HPj): Used by applications sensitive to 
both: delay and traffic. This traffic gets specific transmission resources ensuring that the jitter produced by the 
TDMA transmission scheme of DVB-RCS is minimized. These transmission resources are isolated from other 
type of traffic. 

• Streaming or Streaming Priority (StrP): Typically used for Video traffic or volume based applications. 



5.2 



Flow classification 



The flow classification mechanism will allow RCSTs and the RSGWs provision of different behaviours for different 
type of applications. 

The IP data flow identification is performed by the RCST and the RSGWs upon the following information: 

• IP source address. 

• IP destination address. 

• TCP/UDP source port numbers. 

• TCP/UDP destination port numbers. 

• DSCP value. 

• Protocol type. 

The RCST are configured with a set of masks on the six items listed above. The packets received on the RCST are 
classified according to these masks into different types of flow. 

5.3 Link Layer connection QoS adaptation 

Each time a new flow enters the RSM-B system, the RCST or the RSGW must determine if a suitable connection exists 
for carrying this flow and create it if it does not exist. In this case, the flow type is used to determine the connection 
parameters to be requested to the NCC, in particular the priority and the bandwidth parameters. 

The association between flow types and connection parameters is configured in the RCST MIB. Up to five flow types 
plus a default can be defined. Table 5.1 shows the functional description of each entry in the MIB: 

Table 5.1 : Flow type classification and SLC parameters 
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The default set of SLC parameters is defined by positioning each field of the "header mask" to "any value". 
Based on the type of flow classification, the RCST automatically estimates: 

• SLC - C2P parameters: 

Type of connectivity (unicast/multicast). 

Directionality (unidirectional/bi-directional). 

Traffic type: priority level(LP, HP, HPj or SP). 

Guaranteed Data Rate and Peak Data Rate for that traffic type reception and transmission. 

Activity timeout to release radio resources when no more traffic is present. 

• Different buffering queuing: distinction between HP and LP buffers (SMAC buffers). 

For all traffic, it is possible to define a guaranteed and maximum bit rate. If a guaranteed bit rate is configured for a 
specific traffic category, as soon as a first packet of a flow requesting this level of QoS enters the satellite network, the 
guaranteed capacity is reserved. Once no more packets for this kind of traffic go through the network, the capacity 
allocation timeouts and the radio resources are freed. 

If needed, the terminal requests more capacity. It will be assigned up to the maximum peak rate. 



Network Layer 



6.1 Overview 

The network layer constitutes the external interfaces of the system for the traffic data; it contributes to the provision of 
services such as VoIP, IP multicast, Internet access and LAN interconnection. 

The RCST network layer user plane interfaces are: 

• IP datagrams with the SLC layer. 

• IP datagrams between the RCST and the User Terminal (UT). 

In the control plane the network layer implements a variety of control plane features as needed to support the provided 
services. The control plane of the network layer may be split up in two different parts: 

• A service independent part that includes the interface between the RCST and the NCC to retrieve the MAC 
addresses corresponding to a given IP address. 

• A service dependent part that includes: 

IGMP signalling for multicast provision between RSGW and RCST. 
IGMP signalling for multicast provision between the RCST and the UT. 

For Internet access, exchanges between RCST and RSGW are necessary to get public IP addresses. 
For LAN interconnection, no additional mechanism is necessary. 
The control plane functions of the Network layer include: 

• IGMP proxy functionality towards the RSGW: the RCST acts as IGMP host towards the RSGW. 

• IGMP querier functionality towards the RCST's LAN. 

• IP routing functionality linked to ARP embedded within the C2P. 
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6.2 IP addressing 



The RCST may host several subscriber subnets. Each of these subnets may be composed of public or private IP 
addresses. The subscriber subnet interface with the RCST is called the UI. When several subnets can be reached 
through a RCST, the RCST however participates to a single one: the UI subnet. Reaching several subnets through the 
RCST requires that the subscriber use at least one router between these subnets. 
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Figure 6.1 : Several subnets at RCST user interface side 



6.2.1 



Public IP address 



A subnet requires at least 4 IP addresses (/30). The upper and lower values are reserved for broadcast. The RSM-B 
network allows two subscribers to the same SP to communicate in a single satellite hop. The RSM-B network will 
prevent two subscribers belonging to two different SPs from communicating together in single hop. These subscribers 
must communicate through their respective SP ground network. 

6.2.2 Private IP address 

Using private IP addresses on the RCST User Interface subnet is cheaper (avoiding to request an IP public address), but 
does not provide the user with a way to reach Internet. If the user is willing to reach the Internet, this can be performed 
either through tunnel or through a NAT function as defined in RFC 1631 (see bibliography). 

The Internet Assigned Numbers Authority (lANA) has reserved three blocks of the IP address space for private 
internets as defined in RFC 1918 (see bibliography). These are the three private unicast IP addresses ranges considered 
in RSM-B: 

10.0.0.0 10.255.255.255 (10/8 prefix) 24 bit block (single Class A). 

172.16.0.0 172.31.255.255 (172.16/12 prefix) 20bit block (16 contiguous Class B). 

192.168.0.0 192.168.255.255 (192.168/16 prefix) 16 bit clock (256 contiguous Class C). 

6.3 RSM-B IP routing 
6.3.1 Overview 

The RSM-B routing function is organized as a "decentralized router". Part of the routing functions are located in the 
RCSTs/RSGWs and the other part of them within the NCC, in a client/server like architecture. The NCC is the routing 
server and the RCSTs/RSGWs the clients. Each time a client needs to route an IP packet, it asks the server for the 
information required to route this packet. The routing information sent by the server, is saved in the client. Each client 
must also be configured with some "overall" subnet prefixes authorized for this client. 
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Each time an IP packet is incoming to the RSM-B system, the RCST or the RSGW determines where to send the 
packet, the final target being to get the destination equipment MAC address. The RCST or the RSGW look within their 
routing table and, if the route on the satellite path does not exist, issue an ARP toward the NCC, through the C2P 
connection request message. 

6.3.2 IP routing and address resolution function 

The RCST performs IP routing. Each time an IP packet enters the RCST, this one determines where to send the packet, 
aiming to get either the destination equipment MAC address or the Next Hop Router (NHR) MAC address. 
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Figure 6.2: RCST RSM-B IP routing function 



There exists a close interaction between the routing and addressing functions, and the connection control and 
management. The connection interconnects distant points across the RSM-B network as a route across any type of 
network. And as for a route, the connection between end points is not possible without the knowledge of transit and end 
points (address), and paths linking these points (routing information). All this information is centralized in the NCC, 
which alone makes possible the connection between end points. 

The end point can be any user equipment hosted on a sub-net located behind a RCST (User Interface side). These 
equipment are identified by a unique IP address belonging to one of the sub-net masks attached to the RCST. However, 
since the transmission across RSM-B is based upon the MPEG-2 TS packet format, the knowledge of MPE MAC 
addresses of end RCSTs is mandatory to establish a connection. That means that the NCC provides the mechanisms 
required to associate the IP address of a user equipment into the MPE MAC address corresponding to the hosting RCST 
(mechanism referred as "address resolution"). 

In order to speed-up the connection establishment procedure, the ARP function and the connection establishment is 
simultaneous : the connection establishment request from the RCST includes an ARP request, and the NCC response 
contains both ARP response (destination MAC address, and subnets) and connection parameters. There is only one step 
and one message sent in each direction. 

The RCST routing table consists in two parts: 

• The first part of the routing table is configured with routes depending on the subscription. 

• The second part dynamically modifiable through C2P. 

The configured entries may not be modified or removed by C2P but only through management (such as through SNMP 
or local management interface). The Next Hop squares of the corresponding line of the routing table, for these entries, 
are configured empty (dash) so that the RCST issues an ARP toward the NCC. 
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The following sequence presents the successive steps associated to a new point-to-point bi-directional connection set-up 
between two end points (other parameters than the addressing type are omitted for simplicity): 

1) First of all, the calling RCST (hosting the calling equipment) needs to determine if a new connection should be 
requested or not as shown in figure 6.3: 
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Figure 6.3: RCST RSM-B IP routing and connection set-up 

2) If the results is positive, the calling RCST propagates towards the NCC the request containing the called IP 
address to query the MPE MAC address of the corresponding end RCST (hosting the called equipment). The 
source RCST also transmits the IP address of the calling user equipment, the priority level and a requested 
bandwidth for the connection. 

3) The NCC propagates the calling MPE MAC address and adds the mask addresses of the sub-net associated to 
the calling RCST. This mask obviously contains the IP address of the calling user equipment. 

4) The NCC replies to the request with the called RCST MPE MAC address of the corresponding end RCST 
(hosting the called equipment) and the mask addresses associated to called RCST. This mask obviously 
contains the IP address of the called user equipment, confirmation of the priority level and bandwidth 
requested for the connection. 

5) Each RCST caches the called MAC MPE address/IP sub-net masks pair avoiding to reiterate requests at each 
new incoming IP packet with an IP address belonging to one of the sub-net masks. 
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6) All the sub-nets prefix attached to one RCST are transmitted to the other RCST. 

7) Once the calling RCST queried the called RCST MPE MAC address, it can encapsulate the data over MPEG-2 
TS with the right MPE header and transmit the packets on the connection so established. 

In case of multicast connection, the destination MPE MAC address is a multicast or broadcast MAC address. 

6.3.3 Default route 

The RCST routing table is configured with: 

• one or several prefixes covering all the private IP address ranges of all the subscribers of the satellite network; 

• one or several prefixes identifying the public IP address ranges allowed in the satellite network (this may also 
be specific to each RSCT); 

• optionally, a default route. 

Depending on the satellite network-addressing plan, the RCST may have a default route or not. . A single default route 
is authorized per RCST. 

The usage to the default routing entry will depend on the type of services supported by the RCST. 



• 



• 



• 



The routing table of a RCST involved in an Internet access subscription is configured with a default route 
toward a RSGW of the ISP. 

The routing table of a RCST involved in a corporate access is configured with a default route toward the 
RSGW of the telecom operator. 

The routing table of a RCST involved in a LAN interconnection access (VPN) may be configured with a 
default route toward another RCST of the same satellite network. 



6.4 IP multicast 

RSM-B system supports two types of IP multicast services based on two types of topologies: 

• Star IP multicast. 

• Mesh IP multicast. 

In the Star IP multicast, multicast flows are dynamically forwarded from a RSGW to several RCSTs. Multicast sources 
are on the terrestrial network and forward their multicast flows towards the RSGW. 

In the Mesh multicast, multicast flows are statically forwarded from a source RCST to several destinations RCSTs. 
Multicast sources are on terrestrial network and forward their multicast flows to a source RCST. 

6.4.1 Star IP Multicast 

Star IP Multicast implies distribution of worldwide available IP multicast data flows if the RSGW has Internet Access 
and distribution of MSP, ISP or Corporate dedicated IP multicast data flows. 

The forwarding of multicast flows is dynamic: the IGMPv2 protocol is running between the RCSTs and RSGW for 
multicast group membership set-up. 

The RSGW forwards multicast flows on the uplink only if at least one RCST has requested to join the multicast group 
corresponding to this flow. The RSGW is in charge of managing the memberships so that to send each multicast flow 
only once. 
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6.4.1.1 Topology 

RSM-B Star IP architecture follows the IGMP protocol architecture as defined in TS 102 294 (see bibliography). 
The following figure shows in more detail the network topology for Star IP Multicast: 
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Figure 6.4: Star IP IVIulticast network topology 

The network entities involved in the Star IP multicast network topology are hereafter overviewed: 

• User Terminal (UT). 

A User Terminal is on the IP subnet connected to the RCST through the User Interface. This UT has an IGMP v2 host 
function to subscribe/de-subscribe to a multicast group. 

• Router on the IP subnet of a RCST. 

If there is a router on the path between the RCST and User Terminal, this router is an IGMP v2 Proxy based on the 
Internet Draft Draft-ietf-magma-igmp-proxy-06.txt .The upstream interface is the interface towards the RCST and the 
downstream interface is the interface towards User Terminals. 

• RCST. 

An IGMP v2 Proxy based on the Internet Draft Draft-ietf-magma-igmp-proxy-06.txt is implemented in a RCST. 

The RCST acts as an IGMP Router and Querier on its User interface and it acts as an IGMP Host on the satellite air 
interface. The IGMP proxy avoids the RSGW receiving request message for an IP multicast flow from an UT, on the 
LAN of a RCST, which has already been requested by another UT on the same LAN. The IGMP Proxy knows that the 
IP multicast flow is already transmitted on the TDM and provides it to the new UT without asking the RSGW. This 
enables to reduce the number of IGMP messages sent on the air interface. 

The IGMP proxy forwards multicast data flow received from the satellite air interface to its User Interface according to 
its group membership table. 

• RSGW. 

The RSGW is composed of: 
a GW_RCST; 
an IGMP adapter; 



ETSI 



52 



ETSI TS 102 429-2 V1.1.1 (2006-10) 



a Multicast Edge Router. 

The IGMP Adapter is an IGMP Proxy optimized to satellite environment following specification TS 102 293 (see 
bibliography). The IGMP adapter is based on IGMP v2 proxy and performs specific functions to improve the signalling 
load induced by the IGMP v2 protocol for the satellite networks. It has an interface towards GW-RCSTs and an 
interface towards a Multicast Edge Router. The IGMP host function is standard as defined in RFC 2236 [5]. The IGMP 
Querier function is optimized to the satellite environment having values of timers adapted to a satellite network. 

The Multicast Edge Router is a multicast router with an IGMPv2 Router/Querier function on its interface towards the 
IGMP adapter and a multicast routing function on its other interface. The multicast routing function of the Multicast 
Edge Router is commonly based on PIM-SM. It is in charge of joining or pruning to the group-spanning tree. 

All the IGMP messages are transparently forwarded no decrement of TTL (Time To Live) field value of IP packet, 
inside the RSGW till they reach the Multicast Edge Router. Therefore the GW_RCST transparently forwards all IGMP 
messages without decreasing the TTL field value. 

• Backbone network, ISP or MSP network, Internet, Corporate Network. 

These networks have Multicast Core Routers with multicast routing protocol such as PIM-SM, MBGP, and MSDP. 

6.4.1.2 Protocol stack 
6.4.1.2.1 User Plane 

The RCST User Plane protocol stack follows the structure defined in TS 102 429-1 [3]. 

In the User plane, the RCST is in charge of forwarding multicast packets according to a Group Membership Table. This 
table is used in the User Plane and it is generated and updated by the Control plane. 

The format of the group membership table follows the structure: 

Table 6.1 : Group membership table 



Group address 


Outgoing Interface 


<IP group address> 


<eth/sat interface> 



This table has the list of multicast group addresses having at least one member. The outgoing interface is the interface 
toward group traffic is to be forwarded. In RSM-B system it is the User interface of the RCST. 

6.4.1.2.2 Control Plane 

In the control plane, IGMP v2 messages are exchanged between IGMP Proxy included into RCSTs and the IGMP 
Adapter of the RSGW, and between the IGMP Adapter of the RSGW and a Multicast Edge Router. 
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Figure 6.5: Star IP multicast control plane protocol stacks 
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The type of IGMP v2 messages exchanged over the air satellite interface is: 

• IGMP v2 Generic Query and Specific Group Query are sent by the IGMP Adapter to RCSTs. 

• IGMP v2 Report and Leave messages are sent by RCSTs to the IGMP Adapter. 

The IGMP v2 format messages must be compliant to the RFC 2236 [5]. Particularly all IGMP v2 messages must be 
encapsulated into Ipv4 packets having the Router Alert Option in their IP headers as defined in the RFC 2113 [4]. 

At IP level IGMP v2 messages are characterized by: 

Table 6.2: Characteristics of IGIVIP v2 messages 



IP Header 


Content 


Source IP address 


IP address of the IGIVIP Adapter on its interface towards GW-RCST 
Or the IP address of the RGST on its User interface. 


Destination IP address 


224.0.0.1 ALL-SYSTEIVI for IGMP v2 Generic Query message 
224.0.0.2 ALL-ROUTERS for IGMP v2 Leave message 
Group address (Glass D address) for IGMP v2 Report message and 
IGMP v2 Group specific Query. 


TTL (Time-To-Live) field 


1 


Protocol number 


2 


IP header Option 


Router Alert Option. 



Moreover the NCC periodically sends the Multicast Map table. The MMT is described in annex 1.6 of TR 101 790. This 
MMT gives multicast PID associated to IP multicast addresses. 

Table 6.3: IVIulticast Map Table for Star IP multicast 



Multicast address 


PID 


ALL-SYSTEM (224.0.0.1) 


Multicast PID 


<IP group address> 


Multicast PID 


<1P group address> 


Multicast PID 



6.4.1 .3 RCST Star IP Multicast functions 

The IGMP Proxy included into the RCST has two interfaces. These interfaces must be configured as defined below: 

• An IGMPv2 Host function on the satellite air interface. 

• An IGMPv2 Querier on the User Interface. 
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The following figure shows the RCST IGMP Proxying functionality: 
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Figure 6.6: IGMP proxying overview 

The IGMPv2 messages sent by the RCST towards the IGMP adapter has as IP source address the IP address of the 
RCST in its Air Interface. 

The IGMP v2 proxy shall be configured to receive IGMP v2 Query messages from the IGMP adapter of the RSGW. It 
shall process IGMPv2 messages using the multicast address ALL-SYSTEM (224.0.0.1) without sending an IGMP 
report for this group address towards the IGMP adapter. This IGMP v2 proxy has a membership database consisting of 
the merge of all subscriptions on its downstream interface. 

The IGMP Querier function on the User Interface is configured to be elected as Querier. This entity processes IGMP 
messages received from the User Interface. 

The RCST star IP multicast functions follow the IGMP-specific BSM functional model defined in TS 102 293 (see 
bibliography). 



6.4.1.3.1 



RCST IGMPv2 Host 



The IGMP v2 host shall process as specified in clause 6 of RFC 2236 [5]. It shall process one state diagram per 
multicast address active in the Membership database. 

The IGMPv2 Host must not respond for a group with an address included in 224.0.0.0/24. These are local sub-network 
multicast addresses that do not need to be controlled by IGMP. 

The "Join group" event appears on reception of an "add a group" from the IGMPv2 Querier. In addition to the specified 
actions on the "Join group" event, the IGMPv2 Host shall: 

• Send an IGMP report to the IGMP adapter. The unsoUcited report must not be sent by the IGMPv2 Host if it 
receives a resent report before the unsolicited report timer expires. 

• Add the group to the membership database. 

The "Leave group" event appears on reception of a "remove a group" from the IGMPv2 Querier. In addition to the 
specified actions on the "Leave group" event, the IGMPv2 Host shall remove the group from the Membership database. 
The IGMPv2 Host shall send an IGMP Leave message if its flag is set. If the flag is not set, the IGMPv2 Host must not 
forward an IGMP leave message (silent leave). 

When a General Query is received, the IGMPv2 Host shall act if it is a member of all groups present in the Membership 
database. 

The unsolicited Report Interval of IGMPv2 Host shall be configurable. 
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6.4.1 .3.2 RCST IGMPv2 Querier 

The IGMPv2 Querier shall process clause 7 of RFC 2236 [5] with the following extra actions: 
On the "notify routing +" action, the IGMPv2 Querier shall: 

• Change the group membership table used to forward multicast packets. 

• Send a "add a group" to the IGMPv2 Host. 

On the "notify routing -" action, the IGMPv2 Querier shall: 

• Change the Group Membership table used to forward multicast packets. 

• Send a "remove a group" to the IGMPv2 Host. 
Some parameters of the IGMPv2 Querier shall be configurable: 

• Robustness variable. 

• Query Interval. 

• Query Response Interval. 

To receive IGMP messages and Multicast Traffic sent by the RSGW, the RCST needs to filter the multicast PID 
associated to these data. The multicast PID is indicated into the Multicast Map Table (MMT) forwarded by the NCC. 
The RCST keeps in memory a copy of the last received MMT. The RCST learns the PID use to decode the MMT from 
the Network Layer Information Descriptor received in the TIM_u during the logon process. 

The RCST shall first learn the PID used to forward IGMP messages (IP address 224.0.0. 1). After upon creation of a 
group membership (first IGMP Report message on its User Interface) the IGMPv2 Proxy shall send an internal request 
to check the corresponding multicast PID in the MMT and then updates the list of PIDs to listen to. Upon suppression 
of a group membership, the IGMP Proxy shall send an internal request to retrieve the corresponding PID from the list of 
PIDs to listen to. 

To check the multicast PID corresponding to an IP multicast address, the RCST shall parse the MMT from the 
beginning to end and shall select the first PID corresponding to the IP multicast address. 
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Figure 6.7: Star IP Multicast scenario example 

6.4.1 .4 Connections for Star IP Multicast 

The NCC is in charge of assigning a multicast PID to the RSGW and of periodically sending the Multicast Map Table 
of a satellite network. A typical refresh period for the MMT is 10s. This MMT is updated according to RSGW request 
(Connection Establishment Request for a point-to-multipoint connection). 

IGMP v2 protocol needs a two-way communication: 

• The RSGW sends IGMP v2 messages to all covered TDMs. 

• The RCSTs send IGMP v2 messages to the RSGW. 

Multicast flows need a unidirectional point-to-multipoint connection from the RSGW to all covered TDMs. Then the 
following connections are set-up: 

• A point-to-multipoint connection from the RSGW to all covered TDMs to forward IGMP v2 messages and all 
multicast flows. 
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• A point-to-point connection from each RCST to the RSGW to forward IGMP v2 messages. 

6.4.1 .4.1 Point-to-multipoint connection from the RSGW 

This point-to-multipoint connection is set-up on demand by the RSGW upon reception an IP multicast packet 
(identified by a multicast IP address). 

• Set-up of the connection by the RSGW: 

When the RSGW receives a first multicast packet, the RSGW sends a C2P Connection Establishment 
Request. 

The NCC processes this request and assigns a multicast PID. An entry [IP multicast address-PID] is 
added into the MMT. When the MMT has been updated the NCC sends a C2P Connection Establishment 
Response to the RSGW. 

Once this connection is set-up all multicast IP packets using this IP multicast address are forwarded to 
RCSTs via this connection. 

• Release of the connection initiated by the RSGW: 

This point- to -multipoint connection could be released when the timer associated to this connection 
expires (no more multicast packets are sent by the RSGW). 

The RSGW sends a C2P Connection Release Request to the NCC. The NCC processes this request and 
updates the Multicast Map Table. The NCC removes the entry [IP multicast address - PID] from the 
MMT. 

6.4.1 .4.2 Point-to-point connection from a RCST 

Upon reception of a multicast IP packet encapsulating IGMP messages (Router Alert option and protocol number 2 into 
the IP header), the IP forwarding function forwards this IP packet to the default gateway. The IP address of the default 
gateway is known by the RCST in its unicast routing table. The RCST checks if a connection with its default RSGW is 
already set-up or not. 

• No connection is set up between the RCST and its default RSGW: Connection set-up: 

In this case the RCST sets up a point-to-point-connection with the RSGW. This connection has the same 
characteristics as the one used by to access star services (star connection). 

• A star connection is already set-up between the RCST and its RSGW: 

In this case IGMP messages are forwarded to the RSGW via this star connection. There is no connection 
set-up. 

• Release of the connection: 

This connection could be released when the activity timer associated to this connection either in the 
RCST or in the RSGW expires. The RCST (or the RSGW) could send a C2P Connection Release 
Request to the NCC. 

6.4.2 Mesh IP Multicast 

Mesh IP Multicast provides forwarding of multicast data between RCSTs having a LAN interconnection subscription 
over the RSM-B system. Mesh IP Multicast consists in the distribution of IP multicast flows from a source RCST over 
all TDMs in the same satellite network. 
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6.4.2.1 Topology 

Figure 6.8 gives the network topology to offer Mesh IP Multicast service. 
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Figure 6.8: Mesh IP multicast network topology 



User Terminal (UT). 



A User Terminal is on the IP subnet connected to the RCST through the User Interface. This UT has an IGMP v2 host 
function to subscribe/de-subscribe to a multicast group. 

• Router on the IP subnet of a RCST. 

If there is a router on the path between the RCST and User Terminal, this router is an IGMP v2 Proxy based on the 
Internet Draft Draft-ietf-magma-igmp-proxy-04.txt. The upstream interface is the interface towards the RCST and the 
downstream interface is the interface towards User Terminals. 

Moreover this router is configured to forward some multicast flows to the RCST. The list of authorized multicast flows 
is the same as the one configured into the RCSTs. 

• RCST. 

The RCST is an IGMP v2 Querier to process subscription of UTs on the User Interface. On the air satellite interface a 
RCST has no IGMP function. It forwards multicast data flow received from the air satellite interface to its User 
Interface according to its group membership table when requested. 

In addition a RCST has the list of IP multicast group addresses that authorized to be forwarded to the air satellite 
interface. This list is defined per RCST and is configured by management. An RCST forwards these authorized IP 
multicast flows from the User Interface to the air satellite interface over a point-to-multipoint connection. 

• Multicast addresses. 

Each satellite network managed by a service provider has a pool of IP multicast addresses assigned as recommended in 
the RFC 2365 (see bibliography). Each RCST has pool of IP multicast addresses authorized to be forwarded. 
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6.4.2.2 Protocol stack 
6.4.2.2.1 User Plane 

The RCST user plane protocol stack follows the structure defined in TS 102 429-1 [3]. 

In the User plane a RCST has a group membership table to forward multicast traffic packets from the air satellite 
interface to its User Interface. This table is used in the User Plane and it is generated and updated by the Control Plane. 

The format of the group membership table follows this structure: 

Table 6.4: Group membership table 



Group address 


Outgoing Interface 


<IP group address> 


<eth/sat interface> 



This table has the list of multicast group addresses having at least one member. The outgoing interface is the interface 
toward traffic is forwarded. In RSM-B system it is the User interface of the RCST. 

About IP multicast traffic packets received from the User Interface the RCST forwards them to the air satellite interface 
according to the list of authorized IP multicast addresses. 



6.4.2.2.2 Control plane 
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Figure 6.9: IVIesh IP multicast control plane protocol stack 

In the control plane, IGMP v2 messages are exchanged between IGMP Querier included into RCSTs and User 
Terminals. There is no IGMP Messages exchanged between the RCSTs on the air satellite interface. 
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6.4.2.3 RCST Mesh IP Multicast functions 

Mesh IP Multicast functions require an IGMPv2 querier implemented in the RCST. This RCST querier implementation 
follows RFC 2236 [5]. 

An overview of IGMPv2 querier function is given in the following figure: 
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Figure 6.10: IGMPv2 querier overview 

To receive multicast traffic sent by a RCST, the RCST needs to filter multicast PIDs associated to the traffic. These 
PIDs are indicated into the Multicast Map Table (MMT) forwarded by the NCC. 

The NCC periodically sends a MMT. The MMT is described in the TR 101 790 annex 1.6 and gives the multicast PID 
associated to a multicast IP address. 

Table 6.5: IVIulticast IVIap Table for IVIesh IP multicast 



Multicast address 


PID 


<IP group address> 


PID 


<IP group address> 


PID 


<IP group address> 


PID 



Then the RCST processes the MMT and keeps in memory a copy of the last received MMT. The RCST learns use to 
decode the MMT from the Network Layer Info Descriptor int the TIM_u table received during the log-on. 

Upon creation of a group membership (first IGMP Report message on its User Interface) the IGMP Querier sends an 
internal request to look up the corresponding multicast PID in the MMT and then updates the list of PIDs to listen to. 
Upon suppression of a group membership, the IGMP Querier sends an internal request to retrieve the corresponding 
PID from the list of PIDs to listen to. 
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Figure 6.11 : Mesh IP Multicast scenario example 

6.4.2.4 Connections for Mesh IP multicast 

The Meshed IP Muhicast data service delivery is unidirectional and uses a point-to-multipoint connection originated by 
a source RCST to all TDMs covered by the satellite network. This connection may be an on-demand connection or a 
permanent connection. 

No signalling connection is required for this service because no multicast signalling protocol is running between 
RCSTs. 

6.4.2.4.1 On demand point-to-multipoint from an RCST 

Upon reception of a multicast IP packet the source RCST checks if this IP multicast address belongs to the list of IP 
multicast addresses authorized to be forwarded on the air satellite interface. 

If the multicast address belongs to this list, the RCST checks if a point-to-multipoint connection is already set-up for 
this group. If the connection is already set-up, the RCST forwards the multicast flow via this connection. 

The NCC assigns a multicast PID for this group. The entry [multicast address -PID] is added into the MMT. When the 
MMT has been updated, the NCC sends a C2P Connection Establishment Response to the source RCST. 

Once this connection is set-up all IP multicast packets using this IP multicast address are forwarded to RCSTs via this 
connection. 
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This multicast traffic connection could be released when the activity timer associated to this connection expires (no 
multicast traffic packets sent by the source RCST). 

The RCST sends a C2P Connection Release Request to the NCC. The NCC processes this request and updates the 
Multicast Map Table. The NCC removes the entry [IP multicast address, multicast FID] from the MMT. 

6.4.2.4.2 Permanent point-to-multipoint connection 

A permanent point-to-multipoint connection is characterized by: 

• A start time. 

• A stop time. 

• A multicast group address. 

• A source RCST. 

The NCC is in charge of setting-up the permanent connection for the multicast group address at the start time. The NCC 
will assign a multicast PID for the group. The entry (multicast group address -FID) is added into the MMT. When the 
MMT has been updated, the NCC sends a C2P connection establishment message to the source RCST. 

Once this connection is set-up all IP multicast packets using this IP multicast address are forwarded to RCSTs via this 
connection. 

Upon reception of a multicast IP packet the source RCST checks if this IP multicast address belongs to the list of IP 
multicast addresses authorized to be forwarded on the air satellite interface. 

If the multicast address belongs to this list, the RCST checks if a point-to-multipoint connection is already set-up for 
this group. If the connection is already set-up, the RCST forwards the multicast flow via this connection. 

At the stop time, the NCC releases this permanent multicast traffic connection. When releasing the connection, the NCC 
updates the Multicast Map Table. The NCC removes the entry [IP multicast address, multicast PID] from the MMT. 
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